<?php
/**
 * <https://y.st./>
 * Copyright © 2017 Alex Yst <mailto:copyright@y.st>
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program. If not, see <https://www.gnu.org./licenses/>.
**/

$xhtml = array(
	'title' => 'Learning Journal',
	'subtitle' => 'CS 2301: Operating Systems 1',
	'copyright year' => '2017',
	'body' => <<<END
<h2 id="Unit1">Unit 1</h2>
<p>
	Virtualisation is used in all major operating systems.
	The two operating systems I use myself at home are Debian 9 and Replicant 4.2.
	Both of these systems provide a virtual system for applications to interact with, making it so hardware-specific programs need not be written (though different versions still need to be compiled for different processors).
	In the case of Debian, the standard Linux $a[API] is available to applications.
	Replicant is a fork of a fork of Android (that&apos;s not a typo; it&apos;s a fork of a fork), so all the free parts of the Android $a[API] are available to work with.
	(In Replicant, the proprietary $a[API] methods made available by Google Play Services aren&apos;t present because Google Play services, thankfully, isn&apos;t included.)
	Android&apos;s $a[API] is based on Java, making Java&apos;s standard methods and classes available as well.
	At work, I deal with a third system that will remain unnamed, but it provides the same type of virtualisation for applications to interact with the hardware without needing to know the specifics of that hardware.
	These are the only three operating systems I interact with, so they&apos;re the only places I come in contact with virtualisation, at least directly.
	I don&apos;t have any other electronics (such as televisions, $a[DVD] players, $a[DVR]s, et cetera) in my home besides my microwave oven, conventional oven, and refrigerator/freezer, so I don&apos;t have as much virtualisation in my home as most people do.
	Internet-based services also tend to run on machines that use virtualisation, so I likely come into indirect contact with virtualisation on countless Linux-based systems, as well as $a[BSD] systems, Windows systems, and OS X systems.
	Using this virtualisation, I&apos;m able to run many programs at once.
	I don&apos;t know what all the computer at work runs, but on my laptop, I need to simultaneously run $a[Tor], my basic desktop software, my text editor (I write in my journal and compose all my assignments in $a[XHTML]), my email client, a Web browser, my file manager, and usually at least two instances of a command line emulator, all at once.
	And that&apos;s my minimal setup, when I&apos;m not doing anything out of the ordinary.
	When I&apos;ve got other things to do, I run additional applications while keeping all my usual stuff running.
	The basic desktop software&apos;s composed of many types of applications as well, which all run at once.
	There&apos;s a lot that needs to happen even with this minimal setup!
</p>
<p>
	My name is Alex Yst, and I&apos;m currently working toward my computer science degree here at University of the People.
	I&apos;m agendered, so I&apos;m both an Alexandra and an Alexander (or neither, if you prefer to think of it that way).
	The main language I prefer to use is $a[PHP], but I&apos;m also fluent in Java, Python, $a[XML], $a[XHTML], $a[CSS], and Lua.
	I dabble in JavaScript, but I try to avoid using it when possible for accessibility reasons.
	I maintain a website, and I keep an <a href="https://y.st./en/coursework/">archive of my past coursework</a>.
	I type in English English (as opposed to United States English), so if you&apos;re in the United States, you&apos;ll likely see a lot of my words use an &quot;s&quot; instead of a &quot;z&quot;, and I spell &quot;colour&quot; with a &quot;u&quot;.
	I thought I had an idea of how memory addresses in $a[RAM] were used by applications.
	I thought that the operating system assigned a memory address for the application&apos;s use when the application requested it, and if the application tried to access the memory allocated to another application, the operating system would cause the program to segfault.
	In fact, that&apos;s what I thought a segfault was: an error thrown because an application tried to access memory not allocated to that specific program (or program instance, rather).
	However, it seems the $a[RAM] is virtualised, so there&apos;s no way to even try to access another application instance&apos;s $a[RAM] addresses.
	So what&apos;s a segfault then?
	I&apos;ll need to look into that when time allows, if it&apos;s not covered by the course material.
	The chapter also showed an example of a multi-threaded application coming up with the wrong solution due to sets of instructions not being treated atomically.
	The problem looks very much like my understanding of race conditions.
	I&apos;m really hoping we cover race conditions and how to properly deal with them in our software.
</p>
END
);
